Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-022.txt

Text File | 1992-11-18 | 52.7 KB | 1,451 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 20 Mar 92       Volume 1 : Issue 22

Today's Topics:

    *DESPERATELY SEEKING APPLE COMPUTER JOB*
    Preference files: best way?
    Async filereading only from floppy?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Steve Klingsporn)
Subject: *DESPERATELY SEEKING APPLE COMPUTER JOB*
Date: 1 Feb 92 09:03:01 GMT
Organization: Brown University

Newsgroups: misc.jobs.wanted,misc.jobs.resumes
Subject: Macintosh Programmer seeks Apple/NeXT/Other Job *NOW*
Summary:
Followup-To:
Distribution: usa
Keywords:


Steve Klingsporn
1032 Ashland Avenue
Wilmette, IL  60091
[phone]
[e-mail]
[e-mail]


Saturday, 1 February, 1992


To whom it may concern in Silicon Valley:

My name is Steve, and I'm a 19-year old student in Chicago.  I worked
for Apple's Chicago, IL ("Riverway") Regional Sales Office (Rosemont, IL)
for 2 years, beginning in May, 1989.  I'm back from my first year at school;
I didn't do well -- I had other things on my mind and didn't apply myself.
I can program the Macintosh in C and Pascal, and am learning C++ and MacApp
right now.  I'm an average programmer when it comes to the Mac, but I'm
learning and tend to generally learn everything pretty quickly.

I have this dream -- run away to California (Silicon Valley) and get a job
doing *anything* at Apple or NeXT or some other cool computer company with
the vision I have (Apple's).  I want to change the world, and due to my
bad situation at home, I'm forced to look to move to California for a job
immediately.  I am a really nice & personable guy, and work well with people.
I'm a very experienced computer person, and have been programming off and on
for 10 years.  I need a job.  I want to start over, so to speak.

Eventually, I will continue my higher education.  For now, I just want to
get away from home -- and see what I can do in the programming, R&D,
marketing world.  I'm a dreamer, but remain realistic.  I'm intelligent,
and learn quickly and easily.  I can succeed.

I believe that I could be an asset to the personal computer industry, and
I have references to back up this statement.  If Apple or NeXT or some
other company of that sort has ANY POSITION (AA, Anything), preferrably
Apple and in the PINK projet, System 7, or ATG, I would LOVE to work for you.


I look forward to hearing from you.


Thanks much,

Desperately,

Steve Klingsporn
Macintosh Programmer
[phone]



- -------------------------

From: [e-mail] (Ray Fischer)
Subject:  *DESPERATELY SEEKING APPLE COMPUTER JOB*
Date: 10 Feb 92 22:52:41 GMT
Organization: Computer Science Department, Stanford University.

[e-mail] (Steve Klingsporn) writes ...
>Eventually, I will continue my higher education.  For now, I just want to
>get away from home -- and see what I can do in the programming, R&D,
>marketing world.

Well, this wasn't directed to me directly, but as someone who did the same
thing 15 years ago I might add some useful comments.  I'm not now working
since I returned to school to get eddikated, but I have worked as a
programmer for several years.

Good news/ Bad news.  Good first.

It can be done.  If you can demonstrate that you can produce professional
quality code in an area that is useful to the company (OS, networking,
compilers, tools, etc), preferably by having done it before, and convince the
right person that you can do it, you can get a job.  A better approach is
to demonstrate a useful computer-related skill, get in that way, then
move on to a programming job (which is what worked for me once).

Bad news.  Companies in general, and in particular ones such as Apple
and Next, get lots of people who would like to work for them and think
they can program.  As someone who's worked professionally I'd say that
people WITH BS/MS degrees and no experience are not yet professional
programmers, even though they know a lot about computers.  There are a
lot of people with a degree AND experience who would like to work for
Apple and are not able to because they do not have the skills Apple is
looking for.  You have neither degree or experience, thus you're in for
a difficult time.

>I believe that I could be an asset to the personal computer industry, and
>I have references to back up this statement.  If Apple or NeXT or some
>other company of that sort has ANY POSITION (AA, Anything), preferrably
>Apple and in the PINK projet, System 7, or ATG, I would LOVE to work for you.

Apple requires (in general) an MS (preferably PhD) for people applying
to the advanced technology group.  Operating systems work in general
requires a BSCS minimum plus 2-5 years experience at any company.

Quick test: how familiar are you with semaphores (implementation and use),
deadlock detection, disk scheduling algorithms, the difference between
tasks, processes, & threads, and 2-3 different file system structures
(like MS-DOS, Berkeley FFS, Mac B-Tree, or log-structured file systems).
Know anything about IPC (inter-process communication) and RPC (remote
procedure calls)?  NFS (network file systems)?

I too, would like to work for Apple.  I'll be graduating from Stanford with
an MSCS and 10 years professional experience.  This should give you some
idea of the competition you're facing.

Last words (finally).  Get a degree, THEN bug Apple or Next for a job.
It'll be a LOT easier, and you'll get to do MUCH more interesting things.
It used to be once that getting a job without a CS degree wasn't too
much of a problem.  Not anymore.  Do NOT move here without either money
or a job.  Being homeless is tough, and here you'll need $1000 a month
minimum for basic living expenses.

Good Luck.

Ray
[e-mail]



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  *DESPERATELY SEEKING APPLE COMPUTER JOB*
Date: 13 Feb 92 20:24:41 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ray Fischer) writes:
> I too, would like to work for Apple.  I'll be graduating from Stanford with
> an MSCS and 10 years professional experience.  This should give you some
> idea of the competition you're facing.

> Last words (finally).  Get a degree, THEN bug Apple or Next for a job.
> It'll be a LOT easier, and you'll get to do MUCH more interesting things.
> It used to be once that getting a job without a CS degree wasn't too
> much of a problem.  Not anymore.  Do NOT move here without either money
> or a job.  Being homeless is tough, and here you'll need $1000 a month
> minimum for basic living expenses.

True. Young commercial fields are very tolerant concerning the workforce, and
emerging industries which are screaming for workers will usually look at
the interest and know-how instead of educational merits. However the computing
industry is already in the more stable phase, where the industry really is
looking for a combination of base level education and specialized experience.

I don't think it's impossible to get a job inside any of the big computing
companies without a degree; however it's hard to compete against other
prospects who have a professional title. I've been involved in hiring DTS engineers, and
yes we are not that strict about the right school and right degree. However
if someone shows that he has taken the time and energy to spend at least
4 years in college, and has a degree, it gives the employer a hint about long term
planning, interest and responsibility. And a CS or EE degree certainly shows that.

One final hint, specializing into a particular area (compilers, OS systems,
OOP design, graphics...) always makes it easier to get the right job.


Kent Sandvik/DTS
..yes, he spent 4 years in college, and lived on crisp-bread...



- -------------------------

From: [e-mail] (Boyd Ostroff)
Subject:  *DESPERATELY SEEKING APPLE COMPUTER JOB*
Date: 19 Feb 92 00:28:26 GMT
Organization: Instructional Computing Center, SUNY at Oswego, Oswego, NY

In article <[e-mail]>, [e-mail] (Ray Fischer) writes:
> Not anymore.  Do NOT move here without either money
> or a job.  Being homeless is tough, and here you'll need $1000 a month
> minimum for basic living expenses.

    "California is a garden of Eden,
    a paradise to live in or to see.
    But believe it or not,
    you won't find it so hot
    if you ain't got that do-re-mi!"

(Excerpt from the song "Do-Re-Mi" by Woody Guthrie :-)

.............................................................................
....Boyd Ostroff / Technical Director / SUNY Oswego Department of Theatre....
...............Voice: [phone] /  Fax: [phone]..................
[e-mail] / [e-mail]................



- -------------------------

From: [e-mail] (From A to B)
Subject:  *DESPERATELY SEEKING APPLE COMPUTER JOB*
Date: 19 Feb 92 13:47:23 GMT
Organization: Mantis Consultants, Cambridge. UK.

[e-mail] (Kent Sandvik) writes:
> In article <[e-mail]>, rfischer@Xenon.
> > I too, would like to work for Apple. [...]
> > It used to be once that getting a job without a CS degree wasn't too
> > much of a problem.
>
>                                                         However the computing
> industry is already in the more stable phase, where the industry really is
> looking for a combination of base level education and specialized experience.

Yeah.  If you want to work for Apple, you're probably best off doing a Law
degree.

Hehehe.


mathew

--
Hail Eris! / "Our whole economy's based on fear and death; how long can we get
away with this?" --- Jello Biafra / Message for Kodak: Bring back Dan Bredy! /
PGP RSA public key available on request / Desperately seeking Negativland's U2
CD / Just another would-be Mac owner put off by Apple's monopolistic practices



---------------------------

From: [e-mail]  (Bob Cent)
Subject: Preference files: best way?
Organization: University of Washington
Date: Tue, 4 Feb 1992 01:34:41 GMT

Greetings,

I have the need to open and save preference files from my application.  Is
there an ideal way to deal with this special kind of file?  My searching has
revealed no discussion about it.


Thanks.

Bob Cent, Engineering Technician
[e-mail]
Seattle, Washington





- -------------------------

From: [e-mail] (Chuck McMath)
Subject:  Preference files: best way?
Date: 4 Feb 92 13:38:03 GMT
Organization: MSD

In article <[e-mail]>, [e-mail] (Bob Cent) writes:
>
> Greetings,
>
> I have the need to open and save preference files from my application.  Is
> there an ideal way to deal with this special kind of file?  My searching has
> revealed no discussion about it.
>
>
> Thanks.
>
> Bob Cent, Engineering Technician
> [e-mail]
> Seattle, Washington
>
>

IMHO, the best way to deal with this is to put your preference file in a folder
inside the System Folder - the folder should be called Preferences.  This
is the approach taken by System 7 - my system has a 'Preferences' folder, and
it even has a nifty little special folder icon.  You can do the same thing
under System 6 without any problems.

There are documented ways to find out the vRefNum of the System Folder, and
taking it from there is pretty easy, no?

--chuck mcmath--
[e-mail]
this is where your tax dollars are going - thanks for your support!



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  Preference files: best way?
Date: 5 Feb 92 00:05:38 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Chuck McMath) writes:
>In article <[e-mail]>, [e-mail] (Bob Cent) writes:
>> I have the need to open and save preference files from my application.  Is
>> there an ideal way to deal with this special kind of file?  My searching has
>> revealed no discussion about it.
>IMHO, the best way to deal with this is to put your preference file in a folder
>inside the System Folder - the folder should be called Preferences.  This
>is the approach taken by System 7 - my system has a 'Preferences' folder, and
>it even has a nifty little special folder icon.  You can do the same thing
>under System 6 without any problems.
>
>There are documented ways to find out the vRefNum of the System Folder, and
>taking it from there is pretty easy, no?

If you have a new enough version of MPW, there is an even simpler solution:
Call the System 7 function FindFolder. MPW has glue code that will return the
Preferences folder under System 7 and the System Folder under System 6. While
the latter might be somewhat questionable, I find it very convenient to just
call one function.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_



- -------------------------

From: [e-mail] (Colin "Atilla" Steele)
Subject:  Preference files: best way?
Date: 4 Feb 92 23:14:11 GMT
Organization: Cayman Systems Inc., Cambridge, MA

I have had some limited experience with this, so, for what it's worth:

You need to decide what the preferences are, how they will be used,
and if they will change in size, format, or character in future
verisons.  Next, you've got to figure out what is the best way to
store them.  Sounds easy, right?  Well, lemme toss out a couple of
ideas.  First, you could associate a special "key" with each option,
one that uniquely identifies it.  Part of the key, or somehow
associated with the key, could be a length.  These key-length-option
units could be hierarchical, if your design demanded it.  Or, let's
try something simpler.  You could store options in a text format that,
if need be, the user or tech support rep could look at with any text
editor, and figure out what's going on.

I would suggest creating a special service, say, a "Preferences
Manager," that would hide all of the grody low-level details from the
rest of your system.  Your system just says "gimmie such-and-such a
preference," and the P.M. coughs it up in some standard format.  The
interfaces between the system and the PM and the PM and the file
itself can be as simple or complicated as you want.

Just a few ramblings...
--


- ----------------------------------------------------------------------------
 Colin Steele     | Cayman Systems, 26 Landsdowne St., Cambridge, MA 02139
 [e-mail] | [phone] x209 | applelink D0523 | Fax [phone]



- -------------------------

From: [e-mail] (Mark Jefferys)
Subject:  Preference files: best way?
Date: 5 Feb 92 00:49:12 GMT
Organization: Reed College, Portland, OR

In article <[e-mail]> [e-mail] (Colin
"Atilla" Steele) writes:
% I have had some limited experience with this, so, for what it's worth:

% I would suggest creating a special service, say, a "Preferences
% Manager," that would hide all of the grody low-level details from the
% rest of your system.  Your system just says "gimmie such-and-such a
% preference," and the P.M. coughs it up in some standard format.  The
% interfaces between the system and the PM and the PM and the file
% itself can be as simple or complicated as you want.

Sounds like a NeXT.

Its problem is that the Defaults Database (on the NeXT) will be corrupted
occasionally, causing the user to lose *all* of his preferences for *all*
of his programs.

The Desktop Database (on the Mac) has a smaller problem, since most of the
info can be recovered. (Except comments).


%  Colin Steele     | Cayman Systems, 26 Landsdowne St., Cambridge, MA
02139
%  [e-mail] | [phone] x209 | applelink D0523 | Fax (617)
494-9270

--
Mark Jefferys        Internet: [e-mail]



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  Preference files: best way?
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 5 Feb 1992 18:53:43 GMT

[e-mail] writes:
>Its problem is that the Defaults Database (on the NeXT) will be corrupted
>occasionally, causing the user to lose *all* of his preferences for *all*
>of his programs.

I've been using my NeXT 8 hours a day for over 3 years (yes, I had one
of the first production models).  I've lost my defaults database perhaps
twice.

If you do regular backups, you don't have to worry so much about losing
a few preferences.  If you don't do regular backups, losing a few
preferences is just about the last thing you should be worrying about.

--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
Apparently-To: does more harm than good.




- -------------------------

From: [e-mail] (John Stracke)
Subject:  Preference files: best way?
Date: 6 Feb 92 21:49:37 GMT
Organization: National Science Center Foundation

In article <[e-mail]> [e-mail] (Colin "Atilla" Steele) writes:

   You need to decide what the preferences are, how they will be used,
   and if they will change in size, format, or character in future
   verisons.  Next, you've got to figure out what is the best way to
   store them.  Sounds easy, right?  Well, lemme toss out a couple of

Resources.  That way, you can store the default values in your
application, and saying "GetResource(...)" will fetch from the
preferences file if it's in there, or from your app otherwise.  This
also lets your user edit the app's resources to change the defaults.

/===========================================================================\
|John (Francis) Stracke         |My opinions are my own. | No matter how    |
|Natl. Science Center Foundation|========================/ subtle the       |
|Augusta, GA                    |wizard, a knife between the shoulderblades |
|[e-mail]      |  will seriously cramp his style.          |
\===========================================================================/
(Formerly [e-mail])
--
--



- -------------------------

From: [e-mail]
Subject:  Preference files: best way?
Date: 8 Feb 92 00:50:37 EST
Organization: Cornell University

In article <[e-mail]>,
[e-mail] (John Stracke) writes:
>
> Resources.  That way, you can store the default values in your
> application, and saying "GetResource(...)" will fetch from the
> preferences file if it's in there, or from your app otherwise.  This
> also lets your user edit the app's resources to change the defaults.
>
Actually, this is not a good idea.  If your program is on a server on a
network, and you don't have write privileges to that server, your program
will not be able to change its preferences resources, and will be obnoxious.

It is a much better idea to create a prefs file in the system folder, since
then each user will have their own prefs file on their own machines, and
all will be happy.

Under system 7, of course, you should use the Preferences folder.
WARNING- under international versions of the system, the folder is probably
not called "Preferences" but something else, depending on the language.  Use
the Folder Manager routines.  Your compiler should have the glue that gets
it to work right under any system.

Good luck.
--

- -(0000000000000000000000000000000000000000000000000000000000000000000000)---
 ()00   Dave "Rasferet" Blumenthal   <aka>   [e-mail]   00()
______________________________________________________________________________
I have something to say - | If it works right the  |  #1 Least Desired
It is better to burn out  | first time, then the   |    New Car Option:
than to fade away.        | documentation is wrong.|
 -Kiergan, The Highlander |           -Me          |  Intermittent Steering
______________________________________________________________________________
      ** I'm a .sig virus.  Attach me to your .sig!  Help me spread!  **




- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Want a preferences-file object? (was Re: Preference files: best way?)
Organization: Kalamazoo College
Date: Sat, 8 Feb 1992 19:57:10 GMT

[e-mail] writes:
>
>It is a much better idea to create a prefs file in the system folder, since
>then each user will have their own prefs file on their own machines, and
>all will be happy.
>
>Under system 7, of course, you should use the Preferences folder.
>WARNING- under international versions of the system, the folder is probably
>not called "Preferences" but something else, depending on the language.  Use
>the Folder Manager routines.  Your compiler should have the glue that gets
>it to work right under any system.

I've written a THINK C 5 object that allows for quick'n'easy
implementation of preferences.  It looks for a resource (default 'PREF',
#128, but changeable) with the information you want, in a file (default
name 'AppName Preferences' but very changeable) that's located in the
Preferences folder in the System folder.  It will optionally look in the
application's folder as well.  It will use FindFolder to get the
Preferences folder under 7, and low-level routines to find and/or create
it under 6.  You need to subclass a few things, but it'll take care of
everything from reading and writing the preferences upon request, to
creating the default prefs file if it's not there.

I've had a lot of success using it in conjunction with ResEdit
TeMPLates.  Average turnaround time from thinking "gee, I need another
preferences variable here" to actually having it in the program was
about a minute, not including recompiling.

This object _does_ require the TCL, because it subclasses off of
CResFile.  Theoretically, you could get by if you're using just
CApplication and the CFile hierarchy, but I wouldn't swear to it.
It also uses exceptions.

Anyway, I hereby offer it publicly.  Mail me if you want it.

>      ** I'm a .sig virus.  Attach me to your .sig!  Help me spread!  **

Who started this whole sig virus thing, anyway!?
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Preference files: best way?
Date: 8 Feb 92 20:47:23 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] writes:

   > Resources.  That way, you can store the default values in your
   > application, and saying "GetResource(...)" will fetch from the
   > preferences file if it's in there, or from your app otherwise.  This
   > also lets your user edit the app's resources to change the defaults.

   Actually, this is not a good idea.  If your program is on a server on a
   network, and you don't have write privileges to that server, your program
   will not be able to change its preferences resources, and will be obnoxious.

No, I think the original author was pointing out agood way of
structuring the program; there was no doubt about the resources
being stored in a preferences file locally, but the DEFAULTS are
stored in the application, so that an empty preferences file can
be filled with decent values. THOSE values may be editted using
resedit in the app, either directly or using cut&paste from a
suitable preferences file.

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Ross Brown)
Subject:  Preference files: best way?
Organization: Bell-Northern Research
Date: Mon, 10 Feb 92 15:57:26 GMT

In article <[e-mail]> [e-mail]
(Jon W{tte) writes:
>> [e-mail] writes:
>
>   > Resources.  That way, you can store the default values in your
>   > application, and saying "GetResource(...)" will fetch from the
>   > preferences file if it's in there, or from your app otherwise.  This
>   > also lets your user edit the app's resources to change the defaults.
>
>   Actually, this is not a good idea.  If your program is on a server on a
>   network, and you don't have write privileges to that server, your program
>   will not be able to change its preferences resources, and will be
obnoxious.
>
>No, I think the original author was pointing out agood way of
>structuring the program; there was no doubt about the resources
>being stored in a preferences file locally, but the DEFAULTS are
>stored in the application, so that an empty preferences file can
>be filled with decent values. THOSE values may be editted using
>resedit in the app, either directly or using cut&paste from a
>suitable preferences file.

Here's the way I do preferences:  My preference dialogs have four buttons,
Cancel, Use Defaults, Make Defaults, and OK.  The preferences are stored in
resources in the preferences file, and the defaults for those preferences are
stored in a single resource in the application file.  This "default" resource
is initially absent, so the program supplies "factory defaults".  When the user
clicks on Make Defaults, the "default" resource is created or updated.  Use
Defaults reverts to those settings.  Option + Use Defaults reverts to the
"factory defaults".  If the application resource fork is unwritable, the Make
Defaults box is grayed out.  This way, site administrators can override the
defaults I impose, and protect them from users if desired.  Users are still
free to override the site defaults on a case-by-case basis.

Ross Brown
Bell-Northern Research Ltd.
Ottawa, Ontario, Canada
[e-mail]
Opinions expressed do not necessarily represent those of BNR.



- -------------------------

From: [e-mail] (James Brunner)
Subject:  Want a preferences-file object? (was Re: Preference files: best way?)
Date: 19 Feb 92 18:13:40 GMT

Jamie, I can't seem to E-mail to you.  But I for one am interested in
a preferences file class.  Could you please E-mail to me or post.

By the way, here's my contribution.  The CObject class has an error that
you'll probably never hit, but here it is.  In the routine that returns the
name of a class, they truncate the length to 256 to fit into a Str255
variable.  Like this (from memory so the names may be different):
     length = Min(length,sizeof(Str255));
This should be
     length = Min(length,sizeof(Str255)-1);
or
     length = Min(length,255);

(Of course the sizeof a Str255 is 256 because of the addition of the length
byte).
--
- -------------------------------------------------------------------------
Jim Brunner - ([e-mail])
All opinions are my own and have nothing whatsoever to do with BNR, NT,
NTI, Bell Canada, or any of the BCE corporations or affiliates.



---------------------------

From: [e-mail] (Olle Furberg)
Subject: Async filereading only from floppy?
Date: 2 Feb 92 19:37:21 GMT
Organization: Satellite Image in Kiruna Corporation


Does anybody have any experience with async filereading?

I open the file by PBOpen and then I start reading from
it by PBRead. While it is reading I try to do a small loop
until the reading is done. If the file I'm reading is on a
floppy, the program execution willcontinue under the reading,
but this does not work if the file is on HardDisk (or on a CD).

What am I missing? Isn't it possible to use async filereading reading
with a SCSI?

I'm enclosing the code.


   /Olle



/*
 * Must include an ALRT resource id=1, with a DITL containing
 * one editText item with an ^1, and an OK-button.
 */

#define NIL 0L
#define STILL_READING 1
#define FALSE 0
#define TRUE 1

#include<Types.h>

void ShowError(char *errorstring);
void ToolBoxInit(void);
int ReadFile(void);


main(){
    ToolBoxInit();
    while(ReadFile());
}

ReadFile(){

    Point mypoint;
    SFReply replyrec;
    IOParam pb;
    char mystring[100];
    unsigned long int temp =0;

    mypoint.h = 20; mypoint.v = 20;
    SFGetFile ( mypoint, NIL, NIL, -1, NIL, NIL, &replyrec );
    if (!replyrec.good) return 0; /* Return and exit from appl */

    /* Initialize pb for PBOpen */
    pb.ioCompletion = NIL;
    pb.ioNamePtr = replyrec.fName;
    pb.ioVRefNum = replyrec.vRefNum;
    pb.ioVersNum = 0;
    pb.ioPermssn = fsRdPerm;
    pb.ioMisc = NIL;

    PBOpen((ParmBlkPtr) &pb,TRUE);

    /* Check for error in PBOpen */
    if (pb.ioResult != 0){
        sprintf(mystring,"Error %d while trying to open file",pb.ioResult);
        ShowError(CtoPstr(mystring));
    }

    /* Put file length into pb.ioMisc */
    PBGetEOF ( (ParmBlkPtr) &pb, FALSE );

    sprintf(mystring,"File length = %ld", (long int)pb.ioMisc);
    ShowError(CtoPstr(mystring));

    /* Initialize pb for PBRead */
    pb.ioReqCount = (long int) pb.ioMisc;
    pb.ioPosMode = fsFromStart;
    pb.ioPosOffset = 0;

    /* No completion function, we check the pb.ioResult instead */
    pb.ioCompletion = NIL;

    /* Allocate memory for buffer */
    pb.ioBuffer = NewPtr((unsigned long int) pb.ioMisc);
    if (pb.ioBuffer==NIL) {
        ShowError("\pNot enough memory for buffert");
        return 1; /* Exit if not enough memory */
    }

    /* Start reading async */

    PBRead((ParmBlkPtr) &pb,TRUE);

    /* Do do something else until I/O has terminated */
    for (temp=0; pb.ioResult == STILL_READING;){
        temp++;
    }


    /* Check for error */
    if (pb.ioResult != 0){
        sprintf(mystring,"Error %d in IO",pb.ioResult);
        ShowError(CtoPstr(mystring));
    }

    /* Display result */
    sprintf(mystring,"Did %lu loops, Read %lu bytes.",temp,pb.ioActCount);
    ShowError((char *)CtoPstr(mystring));

    /* Close file, deallocate memory */
    PBClose((ParmBlkPtr) &pb,TRUE);
    DisposPtr(pb.ioBuffer);
    return 1;

}



void ShowError(char *errorstring){
    ParamText((ConstStr255Param) errorstring,(ConstStr255Param)"\p",(ConstStr255Param)"\p",(ConstStr255Param)"\p");
    Alert(1,NIL);
    }

void ToolBoxInit(){
    /* A couple of inits */
    InitGraf(&thePort);
    InitFonts();
    FlushEvents( everyEvent, 0 );
    InitWindows();
    InitMenus();
    TEInit();
    InitDialogs(0L);
    InitCursor();
    MaxApplZone();
}



- ----------------------------------------------------------
Olle Furberg                       Internet: [e-mail]
Satellitbild in Kiruna             Phone: [phone]
Swedish Space Corporation          Fax:   [phone]
                                   Home:  [phone]



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  Async filereading only from floppy?
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: 5 Feb 92 13:28:22

In article <[e-mail]> [e-mail] (Olle Furberg) writes:
>Does anybody have any experience with async filereading?
>
>I open the file by PBOpen and then I start reading from
>it by PBRead. While it is reading I try to do a small loop
>until the reading is done. If the file I'm reading is on a
>floppy, the program execution willcontinue under the reading,
>but this does not work if the file is on HardDisk (or on a CD).
>
>What am I missing? Isn't it possible to use async filereading reading
>with a SCSI?

No. The current SCSI manager executes all calls synchronously.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_



- -------------------------

From: [e-mail] (Steve Christensen)
Subject:  Async filereading only from floppy?
Date: 8 Feb 92 05:16:23 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Olle Furberg) writes:

>What am I missing? Isn't it possible to use async filereading reading
>with a SCSI?

No.  The SCSI Manager is purely synchronous.

steve
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.



- -------------------------

From: [e-mail] (David Phillip Oster)
Subject:  Async filereading only from floppy?
Date: 13 Feb 92 13:27:16 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

In article <[e-mail]> [e-mail] (Steve Christensen) writes:
>No.  The SCSI Manager is purely synchronous.
I timed this as recently as System 6.04, amd at that time, if
you called PBRead on a SCSI device asynchronously, PBRead blocked until the
read was complete, called your completion routine, then returned to its caller.

On the other hand, the floppy driver worked correctly: PBRead() returned
almost immedialtely, and your completion routine was called by the system
some time later, when the data actually arrived.

When will this be fixed? It is ludicrous that the original Mac team in '83
could write better drivers (the original floppy code) than everyone who has
who has come and gone at apple since then.

Machines like the Mac FX have a DMA controller chip that could work
very nicely with async PBRead()s to move the data without loading the
main CPU. The last documentation I saw says that only AUX uses it.

You read the article on "Futures" in the Summer '91 issue of Develop
magazine I want to be able to use the same techniques with reading
disk files: i.e., I want to schedule a read as early as possible, and keep
processing, to overlap processing with disk i/o, only blocking on the disk
when there isn't anything else to do.
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- [e-mail] = {backbone}!well!oster



- -------------------------

From: [e-mail] (Matt Mora)
Subject:  Async filereading only from floppy?
Date: 13 Feb 92 20:28:22 GMT
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (David Phillip Oster) writes:
>In article <[e-mail]> [e-mail] (Steve Christensen) writes:
>>No.  The SCSI Manager is purely synchronous.
>
>When will this be fixed? It is ludicrous that the original Mac team in '83
>could write better drivers (the original floppy code) than everyone who has
>who has come and gone at apple since then.

I seen at MacWorld Expo in SF a company who apperently rewrote the scsi
manager to make it async. They have a program called Scsi Directory 2.0
that can be used on any hard disk to replace the drivers. The company is
called Loviel and is in NY. They were showing there hard RAID system.
where you can actually replace a harddisk while the computer is still
using (actually reading and writing to it) the RAID disk and plug a new one
in without any data loss.

It was truely amazing but its cost was also. If they figured out how to do it
maybe apple can license the software (or in apples case buy the company).

Matt

--
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________



- -------------------------

From: [e-mail] (Matt Mora)
Subject:  Async filereading only from floppy?
Date: 13 Feb 92 21:32:02 GMT
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>In article <[e-mail]> [e-mail] (David Phillip Oster) writes:
>>In article <[e-mail]> [e-mail] (Steve Christensen) writes:
>>>No.  The SCSI Manager is purely synchronous.
>>
>>When will this be fixed? It is ludicrous that the original Mac team in '83
>>could write better drivers (the original floppy code) than everyone who has
>>who has come and gone at apple since then.
>
>I seen at MacWorld Expo in SF a company who apperently rewrote the scsi
>manager to make it async. They have a program called Scsi Directory 2.0
>that can be used on any hard disk to replace the drivers. The company is
>called Loviel and is in NY. They were showing there hard RAID system.
>where you can actually replace a harddisk while the computer is still
>using (actually reading and writing to it) the RAID disk and plug a new one
>in without any data loss.
>
>It was truely amazing but its cost was also. If they figured out how to do it
>maybe apple can license the software (or in apples case buy the company).

Sorry to follow up my own post but I installed an apperently old
version of SCSI director 1.8.9 and these were the results of the speed
test. Now it claims that it does a async read and write but who knows?

- -

[START OF FILE]
SCSI Storage Device Analyzer v1.4
Read the documentation to properly interpret these results!
DO NOT BE MISLEAD BY WHAT YOU ASSUME THE PURPOSE OF THE TESTS ARE!

Test suite run on 1992.02.13 at 13:17:07

==============
REPORT SUMMARY
==============
(Remember that RAM Cache settings affect these timings, note your setting!)
Device Reported Vendor ID:  'QUANTUM'
Device Reported Product ID: 'Q250  76-45004'
Device Reported Firmware:   '70'

SCSI ID:    0
Device Reported Size:        41 MB

Machine:    6, Macintosh ][
Processor:  3, 68020

(Note that speeds of 0.00 indicate a suitable number could not be found.)
Maximum read speed of device is 604.33 KB/Second.
Maximum read speed test: SCSI MANAGER, Inner Rings Read Test

(Note that write testing is sometimes disabled by the user.)
Maximum write speed of device is 0.00 KB/Second.
Maximum write speed test:

    NOTE THAT THESE SEEK TIMES REPRESENT THE TIME TAKEN TO RECEIVE SEEK COMMAND
COMPLETE MESSAGES.  THE DEVICE MAY NOT ACTUALLY DO ANY PHYSICAL ACTION, LIKE
MOVING HEADS, SO THE TIME MAY BE ZERO!  EVEN WHEN THE TIME IS NOT ZERO, THESE
SEEK TIMES DO NOT EVER REPRESENT AVERAGE TRACK-TO-TRACK SEEKING.  THESE SEEK
TESTS SIMPLY MEASURE THE TIME IT TAKES TO EXECUTE SCSI EXTENDED SEEK COMMANDS
VARIOUS WAYS.  THE REASON PROGRAMS CANNOT REPORT TRACK ACCESS TIMES IS BECAUSE
THERE ARE NOT ANY STANDARD SCSI COMMANDS TO ACCESS TRACKS.
  TO AVOID REDUNDENT TYPING, KEEP IN MIND THAT UNLESS MENTIONED ALL READINGS IN
THIS DOCUMENT ARE SCSI TIMINGS AND NOT MAC OS TIMINGS. THEREFORE, UNLESS
USING THIS UTILITY, THE TIMES MIGHT NOT HAVE MUCH BEARING ON NORMAL COMPUTER
USEAGE.

Average Sequential Seek Time:       8.08 milliseconds (ms)
Average Butterfly Seek Time:       22.73 milliseconds (ms)
Average Pattern Seek Time:         15.07 milliseconds (ms)
Outer To Inner Rings Seek Time:    42.80 milliseconds (ms)



=========================
TESTS THAT WERE SELECTED
=========================
Seek
SCSI Manager
SCSI Driver
Mac OS


============================
OTHER SYSTEM CHARACTERISTICS
============================
System:       7.0
Appletalk:    57
FPU Type:     1, 68881
MMU Type:     2, 68851
Physical RAM: 8388608 bytes
Logical RAM:  8388608 bytes
Quickdraw:    2.48
ROM:          262144
ROM Version:  376
Virtual:      CAPABLE
Port A:       IN USE
Port B:       FREE
Printer Name: 'LaserWriter'
Chooser Name: 'Matthew Xavier Mora'

System Extensions
- ---------------


===========================
SCSI DEVICE CHARACTERISTICS
===========================
(Although ambiguous, these are standard SCSI terms)

$00   Peripheral Device Type
FALSE Removable Media
$00   Device Type Qualifier
$01   ANSI Version
$00   Reserved Nibble
$00   Response Data Format
$31   Additional Length
$00   Request Sense Length
$0000 Reserved Integer

Block Range: 0 - 84293
Block Size:  512


==================================
MODE SENSE: CURRENT/CHANGABLE DUMP
==================================
CURRENT    - $0000: 77000008 00000000 00000200 81066003 w............`.
CHANGEABLE - $0000: 77000008 00000000 00000E00 81067FFF w...........
CURRENT    - $0010: 00000000 820A0000 00000000 00000000 ...............
CHANGEABLE - $0010: 00000000 820AFFFF 00000000 00000000 .............
CURRENT    - $0020: B9063AC0 00000000 200C3838 3133302D 9.:@.... .88130-
CHANGEABLE - $0020: B9063BCF 00000000 200C0000 00000000 9.;O.... .......
CURRENT    - $0030: 30313936 4D200316 00040002 00000000 0196M .........
CHANGEABLE - $0030: 00000000 00000316 00000000 00000000 ...............
CURRENT    - $0040: 00200200 0001000A 00124000 00000412 . .......@....
CHANGEABLE - $0040: 00000000 00000000 00000000 00000412 ...............
CURRENT    - $0050: 00029D04 00000000 00000000 00000000 ...............
CHANGEABLE - $0050: 00000000 00000000 00000000 00000000 ................
CURRENT    - $0060: 00003014 4150504C 4520434F 4D505554 ..0APPLE COMPUT
CHANGEABLE - $0060: 00003014 00000000 00000000 00000000 ..0............
CURRENT    - $0070: 45522C20 494E4320 00000000 00000000 ER, INC ........
CHANGEABLE - $0070: 00000000 00000000 00000000 00000000 ................

EVENTUALLY, IN ADDITION TO THE HEX DUMP, THE MODE SENSE DATA WILL BE PRESENTED
IN A SIMPLE, HUMAN READABLE FORM!  MANY DEVICES USE MODE SENSE DIFFERENTLY
MAKING THIS A DIFFICULT TASK.


=============================================================
Track-like Seek (Average ms time of many command completions)
=============================================================
"Track-like" Sequential:         8.08 ms
"Track-like" Butterfly:         22.73 ms
"Track-like" Pattern:           15.07 ms
"Track-like" Outer To Inner:    42.80 ms


============
SCSI MANAGER
============
(These SCSI Manager timings ignore the Mac OS File System and the SCSI Driver)
NOTE:  Write tests were disabled by user.

Maximum Transfer Speeds (KB/Sec): (Same data accessed many times)

                   READ   WRITE
1st Sector        30.17    0.00
Outer Track      487.93    0.00
Inner Track      485.98    0.00
Outer Rings      588.88    0.00 (blocks 0 - 3071, 1.50 MB)
Inner Rings      604.33    0.00 (blocks 81222 - 84293, 1.50 MB)

PATTERN DIRECT READ TIMINGS:

   SYNCHRONOUS, Seed = 1
            R  E  A  D
   BYTES  KB/Sec    Seek
     512   14.92   33.52
    1024   30.17   16.58
    2048   57.02    8.77
    4096  103.43    4.83
    8192  172.17    2.90
   16384  281.74    1.77
   32768  375.65    1.33
   65536  451.76    1.11
  131072  517.31    0.97
  262144  565.89    0.88
  524288  576.90    0.87


===========
SCSI Driver
===========
NOTE:  Write tests were disabled by user.

Maximum Transfer Speeds (KB/Sec): (Same data accessed many times)

   Bytes    READ   WRITE
     512   30.17    0.00 ("sector")
   16384  253.88    0.00 ("track")
 1572864  555.18    0.00 ("rings")

PATTERN SYNCHRONOUS/ASYNCHRONOUS DATABASE SERVER STYLE READ TIMINGS:

   SYNCHRONOUS, Seed = 1  ASYNCHRONOUS, Seed = 1
            R  E  A  D      R  E  A  D
   BYTES  KB/Sec    Seek  KB/Sec    Seek
     512   15.33   32.62   15.25   32.79
    1024   29.50   16.95   29.67   16.85
    2048   55.38    9.03   56.35    8.87
    4096  106.23    4.71  104.75    4.77
    8192  175.74    2.85  177.68    2.81
   16384  284.84    1.76  274.29    1.82
   32768  379.78    1.32  379.78    1.32
   65536  466.74    1.07  474.84    1.05
  131072  522.72    0.96  522.72    0.96
  262144  529.66    0.94  529.66    0.94
  524288  548.57    0.91  543.72    0.92


======
Mac OS
======
(Note that this test cannot be performed on read-only devices such as CD-ROM
 devices.)
(Note that file fragmentation and RAM cache can severly influence these
speeds.)

Maximum Transfer Speeds (KB/Sec): (Same data accessed many times)

            READ   WRITE
First     415.14  390.51 (1572864 bytes)
Average   416.07  391.34 (1572864 bytes)

   Bytes    READ   WRITE
     512  829.06  518.95 ("sector")
   16384  107.11  108.39 ("track")
 1572864  416.07  391.34 ("rings")

PATTERN SYNCHRONOUS/ASYNCHRONOUS READ/WRITE DATABASE SERVER STYLE TIMINGS:

             SYNCHRONOUS, Seed = 1           ASYNCHRONOUS, Seed = 1
            R  E  A  D    W  R  I  T  E     R  E  A  D    W  R  I  T  E
   BYTES  KB/Sec    Seek  KB/Sec    Seek  KB/Sec    Seek  KB/Sec    Seek
     512   15.16   32.97   26.26   19.04   15.58   32.09   26.26   19.04
    1024   30.65   16.31   27.75   18.02   30.83   16.22   27.71   18.05
    2048   52.75    9.48   29.26   17.09   53.41    9.36   29.36   17.03
    4096   65.45    7.64   28.45   17.58   97.05    5.15   28.45   17.58
    8192  161.77    3.09  180.33    2.77  164.42    3.04  180.33    2.77
   16384  230.82    2.17  234.78    2.13  230.82    2.17  236.07    2.12
   32768  269.84    1.85  286.41    1.75  271.30    1.84  292.17    1.71
   65536  335.74    1.49  330.32    1.51  337.58    1.48  328.56    1.52
  131072  373.62    1.34  363.79    1.37  365.71    1.37  360.00    1.39
  262144  410.70    1.22  376.47    1.33  406.35    1.23  374.63    1.33
  524288  477.51    1.05  436.78    1.14  477.51    1.05  438.86    1.14


[END OF FILE]


--
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________



- -------------------------

From: [e-mail] (Steve Christensen)
Subject:  Async filereading only from floppy?
Date: 15 Feb 92 05:32:14 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (David Phillip Oster) writes:
>if you called PBRead on a SCSI device asynchronously, PBRead blocked until the
>read was complete, called your completion routine, then returned to its caller.
>On the other hand, the floppy driver worked correctly: PBRead() returned
>almost immedialtely, and your completion routine was called by the system
>some time later, when the data actually arrived.
>When will this be fixed? It is ludicrous that the original Mac team in '83
>could write better drivers (the original floppy code) than everyone who has
>who has come and gone at apple since then.
>Machines like the Mac FX have a DMA controller chip that could work
>very nicely with async PBRead()s to move the data without loading the
>main CPU. The last documentation I saw says that only AUX uses it.

Making an asynchronous call doesn't mean that the call will, in fact, be
processed asynchronously.  Various limitations will determine how
asynchronously a driver can run.  For the floppy driver, much of a request is
handled that way since many of the operations are so slow (relatively
speaking).

SCSI _drivers_ must be completely synchronous because they rely completely
on the SCSI Manager to talk to their devices, and the SCSI Manager was
originally implemented in a synchronous fashion.

Modifying/rewriting the SCSI Manager to make it asynchronous is no small task
since you have to be completely compatible with the existing SCSI Manager so
you don't break all the existing SCSI drivers who only know about the
synchronous calls.  So even though the IIfx has a DMA SCSI controller, the
DMA mode doesn't do a bit of good if nobody can use it...

steve

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.



- -------------------------

From: [e-mail] (David Phillip Oster)
Subject:  Async filereading only from floppy?
Date: 17 Feb 92 06:11:38 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

In article <[e-mail]> [e-mail] (Steve Christensen) writes:
>Modifying/rewriting the SCSI Manager to make it asynchronous is no small task
>since you have to be completely compatible with the existing SCSI Manager so
>you don't break all the existing SCSI drivers who only know about the
>synchronous calls.

Yes, it isn't a small job, but it is an important job, and its time for
Apple to get off its ass and do it. Call it SCSI++, and let the drivers be
incompatible until the manufacturers do an upgrade. Apple does things that
way all the time. I'm tired of having to deliver slow file i/o to my customers
because my application can't process while it is waiting for the disk. This
is something that Apple needs to change!
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- [e-mail] = {backbone}!well!oster



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Async filereading only from floppy?
Date: 17 Feb 92 12:33:22 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.us> [e-mail] (David Phillip Oster) writes:

   Yes, it isn't a small job, but it is an important job, and its time for
   Apple to get off its ass and do it. Call it SCSI++, and let the drivers be

I believe that's one of the things scheduled for 7.0 but postponed
because of time constraints. It's on the works (since a long time)
under the name of the "New SCSI Manager."

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Jim Cathey)
Subject:  Async filereading only from floppy?
Date: 18 Feb 92 01:40:11 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company

In article <[e-mail]> [e-mail] (Steve Christensen) writes:
>SCSI _drivers_ must be completely synchronous because they rely completely
>on the SCSI Manager to talk to their devices, and the SCSI Manager was
>originally implemented in a synchronous fashion.

So how do we shoot the fool that made this stupid decision in the first
place?  I mean, the original Mac OS was well designed for squeezing the
maximum amount of performance out of the box.  Overlapping I/O out the
ying-yang.  I guess SCSI was so nice and fast (comparatively) that
whoever it was just decided it wasn't worth the bother to do the job
right.  Maybe he was used to the PC...

As you can tell, I've been annoyed about this from day one.  It is long
past time that this, umm, 'feature' was rectified.

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"



- -------------------------

From: [e-mail] (Steven Ritter)
Subject:  Async filereading only from floppy?
Date: 18 Feb 92 01:36:48 GMT
Organization: Doctoral student, Psychology, Carnegie Mellon, Pittsburgh, PA

>Yes, it isn't a small job, but it is an important job, and its time for
>Apple to get off its ass and do it. Call it SCSI++, and let the drivers be
>incompatible until the manufacturers do an upgrade. Apple does things that
>way all the time. I'm tired of having to deliver slow file i/o to my customers
>because my application can't process while it is waiting for the disk. This
>is something that Apple needs to change!
>--
>-- David Phillip Oster - At least the government doesn't make death worse.
>-- [e-mail] = {backbone}!well!oster


Yeah!  What he said.

Steve



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Async filereading only from floppy?
Date: 14 Feb 92 07:45:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (David Phillip Oster) writes:
> Machines like the Mac FX have a DMA controller chip that could work
> very nicely with async PBRead()s to move the data without loading the
> main CPU. The last documentation I saw says that only AUX uses it.

N.B fx is the only Macintosh that has the DMA controller chip. However
I'm not implying that DMA is a bad thing, quite the opposite.

> You read the article on "Futures" in the Summer '91 issue of Develop
> magazine I want to be able to use the same techniques with reading
> disk files: i.e., I want to schedule a read as early as possible, and keep
> processing, to overlap processing with disk i/o, only blocking on the disk
> when there isn't anything else to do.

Yep, you need a File Manager and a SCSI Manager which is fully asynchronous :-).

Kent Sandvik/DTS



---------------------------

End of C.S.M.P. Digest
**********************